Contexto (PR #23)

No branch homepage / PR #23, o SecurityConfig passa a registar CORS com setAllowedOriginPatterns(Arrays.asList("*")) e setAllowCredentials(true). Essa combinação é incompatível com a especificação CORS: com credenciais ativas, o navegador não aceita * como origem, pelo que pedidos cross-origin (como fetch("http://localhost:8080/products") a partir de http://localhost:5173) podem falhar de forma intermitente ou sistemática.

O hook do PR chama a API diretamente em http://localhost:8080, logo o CORS do Spring passa a ser relevante. Hot reload (Vite HMR e Spring DevTools) não depende destes headers CORS; não há impacto esperado na infra de back-end ou nos volumes do compose.

Alteração (mínima)

• Um único ficheiro: SecurityConfig.java.
• .cors(...) com origens explícitas alinhadas ao compose atual: Vite em 5173 e serviço web (nginx) em 4173, em localhost e 127.0.0.1.
• allowCredentials(false) — alinhado ao cliente atual em main (credentials: 'omit' em web/src/lib/api.ts) e ao fetch do PR sem credentials: 'include'.

Nota para o PR #23

• Duplicado de dependência: o commit do PR adiciona springdoc-openapi no pom.xml; em main isso já existe — ao integrar, convém não duplicar o bloco no pom.xml.
• Opcional (ainda menos invasivo no back-end): apontar o front para /api/products (proxy do Vite) elimina CORS no browser em dev; mesmo assim, o CORS restrito aqui é uma rede de segurança razoável.

Verificação

• ./mvnw test na pasta api/ concluído com sucesso.